Сценарии и проблемы

Редактировал(а) Alexandr Fokin 2025/06/06 16:55
Создание нескольких IServiceProvider.
Singleton.
  • Из одного набора IServiceCollection может быть создано несколько объектов IServiceProvider. Но у каждого из них будет свое управление и scope.
    Например если создать 2 экземпляра IServiceProvider, и от каждого из них запросить по одному ISingletonService, то мы получим 2 разных экземпляра ISingletonService.
  • Это может вызвать проблемы так, как обычно IServiceProvider формируется внутри фреймворка.
    Если самостоятельно создать экземпляр IServiceProvider, то получаем отдельное пространство и кривые объекты ISingletonService.
    (Например, если некоторые зависимости необходимы в самом процессе регистрации основного контейнера, конфигурации IServiceCollection)
    Также проблема может усугубиться, если самостоятельно созданный IServiceProvider в некоторых местах выступит в роли Factory/ServiceLocator.
  • Остро эта проблема проявляется для таких ISingletonService, у которых есть свое изменяемое состояние.
Валидация при сборке Di контейнера.services.BuildServiceProvider(
   new ServiceProviderOptions()
    {
        ValidateOnBuild = true,
        ValidateScopes = true
    }
    );
Перегрузка логики GetServicesservice.AddScoped<IEnumerable<string>>
Регистрация одного типа (экземпляра) для нескольких абстракций.services.AddScoped<TImplementation>();

services.AddScoped<TInterface1>(s => s.GetRequiredService<TImplementation>());
services.AddScoped<TInterface2>(s => s.GetRequiredService<TImplementation>());

В случае, если регистрировать через указание интерфейса и типа реализации, то будет создано несколько экземпляров TImplementation, а не один.

Resolve factoryВыбор реализации типа в рантайме (например через использование из AsyncLocal переменной).
Возможное решение: переписывание IServiceCollection, перемещая обычную регистрацию в ключевую, а вместо нее помещая фабричный метод, который содержит логику выбора реализации в зависимости от условий.
Теги: